False write-verification failures on the WebDAV drive

Misconception By design

A tool writing to the WebDAV-mapped Docly drive reports "Write verification failed: <file> is N bytes on disk, expected M". The two numbers are the file's previous and new sizes; the difference is just how much that edit grew the file. The write succeeded. The cause is Windows' WebDAV redirector (MRxDAV) caching file size in its FileInformationCacheLifeTimeInSec (60s default) metadata cache, so an immediate stat after a write returns the pre-write size. Docly stores content verbatim and round-trips bytes exactly, and its server-side ETag / no-cache headers cannot invalidate this cache because the redirector does not ETag-revalidate cached metadata. The reliable fix is client-side: set FileInformationCacheLifeTimeInSec to 0 in the registry and restart WebClient.

What you'll see

An AI coding agent or editor writing files to a WebDAV-mapped Docly drive (L:) reports a write failure of the form:

Write verification failed: <file> is 11855 bytes on disk, expected 11862

It happens on every edit, deterministically rather than randomly. The file in Docly is actually correct — opening or re-reading it shows the new content. The message comes from the client's own post-write size check (for example Claude Code's), not from Docly.

What's actually happening

The two numbers are the old and new file sizes, not a corrupted write. 11855 is the size of the previous version of the file; 11862 is the new one. The difference (here, 7 bytes) is simply how much that particular edit grew the file. It is not a mis-serialised version of the new content.

The content round-trip does not lose bytes. Docly stores the written text verbatim and returns Encoding.UTF8.GetBytes(content) on GET, so for valid UTF-8 without a BOM the byte count that comes back is exactly what was PUT. A genuine round-trip cannot drop 7 bytes. (The only content-level exception is a UTF-8 BOM being stripped — and that is 3 bytes, not 7, and agents normally write without a BOM.) So the mismatch is a stale reported size, never lost data.

Root cause: the MRxDAV metadata cache

Windows' built-in WebDAV client (the WebClient service / MRxDAV redirector) caches file metadata — including size — on a purely time-based schedule, not via HTTP cache semantics. The relevant parameters live under HKLM\SYSTEM\CurrentControlSet\Services\WebClient\Parameters (and mirror keys under MRxDAV\Parameters):

FileInformationCacheLifeTimeInSec : 60        # how long file info (incl. size) is cached before re-fetch
FileNotFoundCacheLifeTimeInSec    : 60        # how long "not found" is cached
FileAttributesLimitInBytes        : 1000000   # max total attribute/PROPFIND size per folder

For up to 60 seconds after the redirector has learned a file's size, it will answer a stat from that cache without asking the server. When the client writes the file and immediately stats it, it can read the pre-write size straight from the cache and conclude the write failed.

Why it fails every time, not just occasionally

The metadata cache is populated by read / PROPFIND operations (for example a directory listing before an edit), not necessarily refreshed by the redirector's own PUT. So the sequence write → immediate stat reads the previously-cached size from the last listing and fails deterministically. A pure 60-second timeout would let some writes succeed after an idle period; "every edit fails" fits a cache that is re-filled by a listing before each edit.

Why server-side headers do not fix it

Docly already returns a fresh ETag built from (Modified, Filesize) and Cache-Control: no-cache, must-revalidate on Drive responses, and maintains Document.Filesize so that the ETag and getcontentlength always report the same, current number. But the redirector's metadata cache is time-based and does not ETag-revalidate cached metadata. no-cache governs the HTTP content cache (the GET body), not MRxDAV's FileInformation cache. No server-side change can invalidate this client cache — the fix has to be client-side.

What to do

Do not treat it as data loss

The write almost certainly succeeded. Confirm by reading the file's content back (not its reported size) — with the caveat in the next section for a file that has just been created. Do not re-run the write in a panic, and above all do not switch to a more dangerous tool (shell-escaped node -e, hand-built writes) to "force it through" — that is how false verification failures turn into real outages. See The site drive is WebDAV not a disk.

Stale content, not just stale sizes

Reading the content back is the right check for an in-place edit of a file that already exists, but it is not sufficient immediately after a new document is created. The redirector caches the file's data as well as its metadata, so a read straight after the copy can return the bytes as they were written — before the Drive added its registration metadata. The symptom is a newly created .docly that appears to have no Guid and still carries its placeholder Created and Modified timestamps, which reads as "registration failed" when it in fact succeeded.

Two views of the same file can disagree in the same moment: a directory listing reporting the true post-registration size while a direct stat on the same path still reports the pre-registration one. When they disagree, trust the listing — it is the one that re-fetches.

To read the authoritative bytes, copy the file off the WebDAV drive and parse the local copy:

Copy-Item -LiteralPath $live -Destination $local
Get-Content -LiteralPath $local -Raw | ConvertFrom-Json | Select-Object Guid
# Guid is present once the Drive has registered the document

See Creating new docly files for what successful registration adds.

Re-writing is safe (no doubling)

Docly's PUT is a full overwrite (the document's content is replaced, not appended). A client that re-PUTs the whole file — as Claude Code's Write/Edit does — simply stores the same complete content again, so there is no risk of the change being applied twice. The doubling risk only applies to tools that do append/delta writes against a write they believe failed.

The reliable fix (client-side, admin, system setting)

Disable the metadata cache on the machine running the agent so every stat hits the server:

Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\WebClient\Parameters" -Name FileInformationCacheLifeTimeInSec -Value 0
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\WebClient\Parameters" -Name FileNotFoundCacheLifeTimeInSec -Value 0

net stop WebClient
net start WebClient

This is a machine-level change to a system service, not a Docly code change. It belongs to whoever owns the machine — an agent should surface it, not perform it. Setting FileNotFoundCacheLifeTimeInSec to 0 as well is optional but removes the related 60-second negative-cache behaviour described in the companion article.

What does not work

Server-side header tweaks. no-cache/ETag on Drive responses cannot invalidate the redirector's metadata cache, because it does not ETag-revalidate metadata. Low cost, but no effect.
Waiting out the timeout mid-session. Because a directory listing re-fills the cache before each edit, idling does not reliably clear the stale size for the next write.

Rule of thumb for agents

"Write verification failed: is N bytes, expected M" on a Docly WebDAV mount is a false alarm from the client's own size check. N is the old size, M is the new one; the write succeeded and Docly round-trips bytes exactly. Confirm by reading the content back — and for a file that has just been created, copy it off the drive first, because the content cache is stale too. Never report it as data loss, and never re-PUT into a more dangerous tool. The real fix is FileInformationCacheLifeTimeInSec=0 on the client machine.